home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14625 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.4 KB
  1. Path: news.salford.ac.uk!aber!not-for-mail
  2. From: pcg@aber.ac.uk (Piercarlo Grandi)
  3. Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  4. Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
  5. Date: 31 Mar 1996 23:05:34 +0100
  6. Organization: Prifysgol Cymru, Aberystwyth
  7. Sender: pcg@osfb.aber.ac.uk
  8. Message-ID: <vwjg2ao6hqp.fsf@osfb.aber.ac.uk>
  9. References: <4irn11$7ln@mimas.brunel.ac.uk>
  10.     <Pine.Sola.3.91.960322041345.17711C-100000@ux5.cso.uiuc.edu>
  11.     <4j03p4$fbt@hoho.quake.net> <Doq3sv.MzA@research.att.com>
  12. Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  13. NNTP-Posting-Host: osfb.aber.ac.uk
  14. In-reply-to: bs@research.att.com's message of Sat, 23 Mar 1996 13:50:55 GMT
  15. X-Newsreader: Gnus v5.0.15
  16.  
  17. >>> On Sat, 23 Mar 1996 13:50:55 GMT, bs@research.att.com (Bjarne
  18. >>> Stroustrup <9758-26353> 0112760) said:
  19.  
  20. bs> billf@jovial.com (Bill Foote) writes
  21.  
  22. billf> It's not too hard to come up with examples where it would be nice
  23. billf> to have resumable exceptions.  One example is resource
  24. billf> acquisition.  Upon failure to acquire a resource (a file
  25. billf> descriptor, some memory, etc.) it might be nice if a top-level
  26. billf> exception handler could try to free up some resources, and if it
  27. billf> can, try to resume from the exception.
  28.  
  29. Uh, but that's not an exception: that's more or less speculative
  30. execution. More on this point later.
  31.  
  32. bs> This point, and many others were seriously studied by the C++ standards
  33. bs> committee before it approved my design of exception handling for C++.
  34. bs> The arguments for and against resumption can be found in chapter 16 of
  35.  
  36. bs>     Bjarne Stroustrup:
  37. bs>     The Design and Evolution of C++
  38. bs>     Addison-Wesley ISBN 0-201-54330-3
  39.  
  40. bs> together with a description of the complete language features and examples
  41. bs> of their use.
  42.  
  43. bs> Here, I'd like to quote a key section:
  44.  
  45. bs> [ ... a lot of experience shows that most language implementors find
  46. bs> out, often to their surprise, that termination is almost universally
  47. bs> cleaner and preferred).
  48.  
  49. Actually, let me add the Ultimate Truth about exception, to support
  50. this, not just experience; exceptions are a widely misunderstood
  51. concept, often commingled with interrupts and other unrelated subjects
  52. (in some cases exceptions have been considered even *values*).
  53.  
  54. Let's tart from the beginning: a program/module/function that implements
  55. a total function cannot possibly have exceptions; conversely an
  56. exception can only arise when a program/module/function does not
  57. implement a total function.
  58.  
  59. An exception happens when a bit of code implementing a partial function
  60. is fed data outside the codomain of the total function.
  61.  
  62. Using Dijkstra's if-fi, an exception happens *iff* the data do not
  63. satisfy the precondition of an if-fi construct somewhere; for example:
  64.  
  65.     float sqrt(float n)
  66.     {
  67.       if
  68.          n > 0 -> ...
  69.       [] n == 0 -> return 0;
  70.       fi
  71.     }
  72.  
  73. A code segment may implement a partial function for one of just two
  74. reasons:
  75.  
  76.  * the function is *intrinsically* partial, in which case its
  77.    application to the given data is in error, and thus execution must
  78.    terminate.
  79.  
  80.  * the function is not necessarily partial, but there are several
  81.    conceivable alternatives on how to make it total, and the author of
  82.    the code segment does not want to force a particular definition on
  83.    the use of the function.
  84.  
  85. It is *only* in the latter case that exception handling makes any sense,
  86. more or less obviously.
  87.  
  88. An example might be assigning a meaning to 'operator /' when the
  89. operands are zero: should '0/0' be 1? An error? Infinity? All these are
  90. legitimate choices, that should not be preempted.
  91.  
  92. Therefore exception handling reduces to simply providing a mechanism by
  93. which the *author* of a code segment provides a mechanism by which the
  94. *user* of that code segment can specify additional cases, as for example
  95. in:
  96.  
  97.     float sqrt(float n)
  98.     {
  99.       if
  100.          n > 0 -> ...;
  101.       [] n == 0 -> return 0;
  102.       [] n < 0 -> return sqrt_negative(n);
  103.       fi
  104.     }
  105.  
  106. where the only difficulty is that sqrt_negative must be dynamically
  107. scoped instead of statically scoped, for it must be redefinable by the
  108. *user* of the procedure.
  109.  
  110. This again means that termination is the only possible outcome for this
  111. case too.
  112.  
  113. The exception facility of e.g. C++ is merely a (rather ad-hoc and
  114. opaque) way of allowing the definition of what are in effect dynamically
  115. scoped procedure names, forcibly coupled with non-local control
  116. transfer.
  117.